第 1 篇給過一個請求：

{
  "model": "claude-opus-5",
  "max_tokens": 1024,
  "messages": [
    { "role": "user", "content": "我叫 Jim，請記住這件事。" }
  ]
}

那一篇說，這個結構會跟著我們走完七層，後面每加一層，都是在 messages 裡多塞一點東西，或是在外面多包一層流程。走完了，這篇把它攔下來看。

七層之後的同一個請求

我開了一個小專案 shop-api，把前面幾層的東西各放一份進去：一份 CLAUDE.md，內容是評估集第三層附上的那種團隊筆記（第三層），一則先在另一個對話裡請 Claude Code 記下的記憶「我負責 order-api，changelog 要署名 order-api 團隊」（第四層），一個寫 changelog 格式的技能（第五層），一個只能讀檔的審查子代理（第七層）。然後只打一句話：

把最近三則 commit 整理成 changelog.md。寫完交給 changelog-reviewer 審查，照審查意見改到通過為止。

整個過程經過 token-inspectour（2026-10-13，Claude Code 2.1.296，Claude Opus 5.5，沒接 MCP，也不載入我自己使用者層的設定）。主代理送了 3 個請求，中間交辦一次審查，一次就通過，連子代理在內總共 0.12 美元。下面是最後一圈送出去的那個請求，每一塊的詞元數來自 count_tokens。分到哪一層是我分的，依據是那一塊屬於哪一層的能力，例如系統提示詞算 Claude Code 自己的第二層指令：

這個請求裡看得到五件事：

• 你打的那一句是 49 個詞元，佔 0.1%。 其餘 99.9% 是 Claude Code 替你放進去的。第 1 篇說工具那一層會「偷偷把別的東西也一起放進那段文字裡」，第 23 篇量到你輸入的不到 1%，這次換成一個七層都用上的任務，一樣不到 1%。
• 最大的一塊是工具定義。 24 個內建工具的說明（圖上 Agent 那一個算在第七層），這次只用了 Skill、Bash、Write、Agent 四個。第 23 篇那次 82,574 個詞元、89 個工具，差距主要來自那次接著的 MCP 伺服器。技能平常在清單裡只佔一行描述（23 個詞元），用到才把內容讀進來，這次讀進來的是 82 個（第 19 篇）。
• 33,981 個詞元裡，32,423 個是快取讀的。 每一圈重送整段前綴，靠的是第 4 篇的快取才付得起。
• 記憶也進了審查子代理的窗口。 子代理的請求是另一個窗口，最後一個請求 3,221 詞元，工具只有 Read，主代理交辦時沒提記憶，但 CLAUDE.md 和那則 183 個詞元的記憶一樣在裡面。第 28 篇講資訊在代理之間溜進來，這是一個實例。
• 記憶進了窗口，不等於會被照做。 changelog 最後沒有署名，Claude 的說明是：記憶寫的是 order-api 的規則，這個 repo 是 shop-api，所以沒套用。第 12 篇擔心的是寫進去的記憶會被一直照做，這次看到的是另一面：要不要照做，是模型讀了之後當下判斷的。這次判斷得有沒有道理，可以討論。

這個請求的骨架還是第 1 篇那三樣：model、max_tokens、messages，只是 max_tokens 從 1,024 變成 128,000。多出來的 system、tools，以及 thinking、stream 這類設定，都是同一個呼叫的欄位。七層加上去的東西，全部在這一個請求裡。

三個洞，各補在哪裡

第 1 篇說，你今天用的每一個代理功能，本質上都是在補三個洞：

三個洞都是用同一種方法補的：把東西放進窗口。所以每補一個洞，請求就長一點，帳單也跟著長。

七層的能力與代價

報名時的簡介說，每一個技術節點都要問：多了什麼能力，又多付了什麼代價。七層收在一張表：

怎麼知道一層值不值得加，是第 29 篇的題目。

路線圖：你的問題需要第幾層

第 24 篇引過 Anthropic〈Building effective agents〉的建議：先找最簡單的解法，需要才加複雜度。把三十篇攤開，上半是七層照順序疊上去、各補第 1 篇的哪個洞，下半是這個系列建議的做法：

寫成步驟是這樣：

1. 先只用第一、二層，同時備好一套評估集（第 4 篇）。
2. 看它錯在哪裡，再決定加哪一層：
   • 它不知道答案 → 第三層，把資料給它。
   • 它忘了上次說過的事 → 第四層，記憶。
   • 它做不到，只能回你一段文字 → 第五層，工具。
   • 步驟要它自己決定、做到完 → 第六層，迴圈。
   • 任務拆得開、一個窗口裝不下，或需要一個跟寫的人分開的審查者 → 第七層。
3. 每加一層，重跑同一套題，把費用一起記。

第三步是最容易省略的一步。第 28 篇加了第七層，分數一樣是 8 分，費用多了六成，那一層就是這套題用不到的那一層。

有了評估集和分數，連第二層本身都能交給程式去調。第 2 篇說反覆調提示詞其實是在搜尋，並提到 DSPy 會把這件事自動化：DSPy（Khattab et al., 2023）把一串模型呼叫寫成模組，再由它的編譯器自己產生、挑選範例，把你指定的分數往上推。

loop、agent、harness、graph

第六、七層的八篇是照一條線排的，每一段都是在同一個呼叫外面多包一層：

1. loop（第 21 篇、第 22 篇）：代理就是一個 while。送出、開工具單、接回結果、再送，沒有工具單就停。接著補上停得對的煞車，以及讓它少繞幾圈的反思與規劃。
2. harness（第 23 篇、第 24 篇）：包著那個迴圈的整套東西，系統提示詞、工具定義、記憶、權限、煞車都在這裡。上面那個請求的 99.9%，就是 harness 放的。到這裡是一個代理的天花板。
3. 多個窗口（第 25 篇）：一個窗口不夠，就讓主代理把工作交給子代理，每個子代理各自一個窗口。
4. graph（第 26 篇到第 28 篇）：把幾個迴圈用節點和邊接起來，誰先誰後、什麼條件退回、哪一步停下來等人，都畫在圖上，每一步存一份檢查點。

裡面那個 messages 呼叫，從第 1 篇到這裡沒有變過。

這一篇多了什麼，又多付了什麼

多了什麼能力：看得見七層加上去的東西，最後都落在同一個請求的哪個位置、各佔多少詞元，知道三個洞各補在哪一層、補完還留下什麼，也有一個依錯誤決定加哪一層的流程。

多付了什麼代價：一個 99.9% 不是你寫的請求。你打的那一句之外，每一個詞元都有人替你決定了要放進去，而你要為它付錢、為它負責。

最後

第 1 篇分了兩種進步：「模型變聰明了」，和「工具把更對的東西塞進去了」。這 30 篇講的幾乎都是後者。模型的權重在推論時一個位元都不會動（第 5 篇），我們能動手改的，從頭到尾就是那個請求裡放什麼、外面包幾層。

這個系列裡「它到底送了什麼」的量測，多半是用我自己寫的開源工具 token-inspectour 攔的。如果你也想拿自己的專案量量看，歡迎試試，也很歡迎直接到 GitHub 上開 issue 或送 pull request，一起把它做得更好。

這個系列就寫到這裡。只帶過、沒有展開的，像語音和即時（realtime）代理、微調，之後會再寫成新的文章。

延伸閱讀

• token-inspectour：拿自己的專案重現這個系列的量測。
• Building effective agents（Anthropic, 2024）：工作流程與代理的分界，以及先找最簡單的解法。
• Demystifying evals for AI agents（Anthropic, 2026）：加一層之前，怎麼量值不值得。